home *** CD-ROM | disk | FTP | other *** search
/ CD ROM Paradise Collection 4 / CD ROM Paradise Collection 4 1995 Nov.iso / hamradio / ax25.zip / AX25.DOC
Text File  |  1994-07-14  |  66KB  |  1,573 lines

  1. --------------------------------------------------------------------------
  2. AX25.DOC
  3.  
  4.          AX.25 Amateur Packet-Radio Link-Layer Protocol
  5.                     Version 2.0  October 1984
  6.  
  7.  
  8. 2.  AX.25 Link-Layer Protocol Specification
  9.  
  10. 2.1  Scope and Field of Operation
  11.  
  12.         In  order  to  provide  a  mechanism  for  the   reliable 
  13. transport  of  data  between  two  signaling  terminals,  it   is 
  14. necessary  to define a protocol that can accept and deliver  data 
  15. over a variety of types of communications links.  The AX.25 Link-
  16. Layer  Protocol is designed to provide this service,  independent 
  17. of any other level that may or may not exist.
  18.  
  19.         This protocol conforms to ISO Recommendations 3309,  4335 
  20. (including DAD 1&2) and 6256 high-level data link control  (HDLC) 
  21. and  uses  some terminology found in these  documents.   It  also 
  22. conforms with ANSI X3.66, which describes ADCCP, balanced mode.
  23.  
  24.         This  protocol  follows,  in principle,  the  CCITT  X.25 
  25. Recommendation,  with the exception of an extended address  field 
  26. and  the addition of the Unnumbered Information (UI)  frame.   It 
  27. also follows the principles of CCITT Recommendation Q.921  (LAPD) 
  28. in the use of multiple links, distinguished by the address field, 
  29. on a single shared channel.
  30.  
  31.         As  defined,  this  protocol will work  equally  well  in 
  32. either half- or full-duplex Amateur Radio environments.
  33.  
  34.         This protocol has been designed to work equally well  for 
  35. direct  connections between two individual  amateur  packet-radio 
  36. stations or an individual station and a multiport controller.
  37.  
  38.         This  protocol allows for the establishment of more  than 
  39. one  link-layer  connection  per  device, if  the  device  is  so 
  40. capable.
  41.  
  42.         This  protocol  does not  prohibit  self-connections.   A 
  43. self-connection  is considered to be when a device establishes  a 
  44. link  to  itself using its own address for both  the  source  and 
  45. destination of the frame.
  46.  
  47.         Most  link-layer  protocols assume that one  primary  (or 
  48. master)  device  (generally  called  a  DCE,  or  data   circuit-
  49. terminating equipment) is connected to one or more secondary  (or 
  50. slave)  device(s)  (usually  called a DTE,  or  data  terminating 
  51. equipment).   This type of unbalanced operation is not  practical 
  52. in a shared-RF Amateur Radio environment.  Instead, AX.25 assumes 
  53. that  both  ends  of  the link are of  the  same  class,  thereby 
  54. eliminating  the two different classes of devices.  The term  DXE 
  55. is  used in this protocol specification to describe the  balanced 
  56. type of device found in amateur packet radio.
  57.  
  58. 2.2  Frame Structure
  59.  
  60.         Link  layer packet radio transmissions are sent in  small 
  61. blocks of data, called frames.  Each frame is made up of  several 
  62. smaller groups, called fields.  Fig.1 shows the three basic types 
  63. of  frames.  Note that the first bit to be transmitted is on  the 
  64. left side.
  65.  
  66.  
  67.  
  68.         First
  69.         Bit Sent
  70.  
  71.           Flag      Address     Control     FCS      Flag
  72.         01111110  112/560 Bits  8 Bits    16 Bits  01111110
  73.  
  74.                 Fig. 1A -- U and S frame construction
  75.  
  76.  
  77.  
  78.         First
  79.         Bit Sent
  80.  
  81.  Flag      Address      Control    PID    Info.       FCS      Flag
  82.  01111110  112/560 Bits   8 Bits   8 Bits  N*8 Bits   16 Bits  01111110
  83.  
  84.                 Fig. 1B -- Information frame construction
  85.  
  86.  
  87.  
  88.         Each field is made up of an integral number of octets (or 
  89. bytes), and serves a specific function as outlined below.
  90.  
  91. 2.2.1  Flag Field
  92.  
  93.         The flag field is one octet long.  Since the flag is used 
  94. to  delimit  frames, it occurs at both the beginning and  end  of 
  95. each  frame.  Two frames may share one flag, which  would  denote 
  96. the  end of the first frame, and the start of the next frame.   A 
  97. flag consists of a zero followed by six ones followed by  another 
  98. zero,  or  01111110 (7E hex).  As a result of bit  stuffing  (see 
  99. 2.2.6,  below),  this sequence is not allowed to  occur  anywhere 
  100. else inside a complete frame.
  101.  
  102. 2.2.2  Address Field
  103.  
  104.         The address field is used to identify both the source  of 
  105. the  frame and its destination.  In addition, the  address  field 
  106. contains  the  command/response information  and  facilities  for 
  107. level 2 repeater operation.  
  108.  
  109.         The encoding of the address field is described in 2.2.13.
  110.  
  111. 2.2.3  Control Field
  112.  
  113.         The  control field is used to identify the type of  frame 
  114. being  passed  and  control several attributes  of  the  level  2 
  115. connection.   It  is  one octet in length, and  its  encoding  is 
  116. discussed in 2.3.2.1, below.
  117.  
  118. 2.2.4  PID Field
  119.  
  120.         The  Protocol  Identifier  (PID) field  shall  appear  in 
  121. information  frames (I and UI) only.  It identifies what kind  of 
  122. layer 3 protocol, if any, is in use.
  123.  
  124.         The PID itself is not included as part of the octet count 
  125. of the information field.  The encoding of the PID is as follows:
  126.  
  127.  
  128.  
  129.   M      L
  130.   S      S 
  131.   B      B
  132.   yy01yyyy AX.25 layer 3 implemented.
  133.   yy10yyyy AX.25 layer 3 implemented.
  134.   11001100 Internet Protocol datagram layer 3 implemented.
  135.   11001101 Address resolution protocol layer 3 implemented.
  136.   11110000 No layer 3 implemented.
  137.   11111111 Escape character.  Next octet contains more Level 3
  138.            protocol information.
  139.  
  140.  
  141.  
  142.         Where:
  143.  
  144.         A y indicates all combinations used.
  145.  
  146.         Note:
  147.  
  148.         All  forms  of  yy11yyyy and yy00yyyy  other  than  those 
  149. listed  above  are  reserved  at this time  for  future  level  3 
  150. protocols.   The  assignment of these formats is  up  to  amateur 
  151. agreement.   It  is  recommended that the  creators  of  level  3 
  152. protocols   contact  the  ARRL  Ad  Hoc  Committee   on   Digital 
  153. Communications for suggested encodings.
  154.  
  155. 2.2.5  Information Field
  156.  
  157.         The  information field is used to convey user  data  from 
  158. one  end of the link to the other.  I fields are allowed in  only 
  159. three  types of frames:  the I frame, the UI frame, and the  FRMR 
  160. frame.   The  I  field can be up to 256 octets  long,  and  shall 
  161. contain  an integral number of octets.  These  constraints  apply 
  162. prior to the insertion of zero bits as specified in 2.2.6, below.  
  163. Any  information  in the I field shall be passed along  the  link 
  164. transparently,  except  for the zero-bit  insertion  (see  2.2.6) 
  165. necessary  to prevent flags from accidentally appearing in the  I 
  166. field.
  167.  
  168. 2.2.6  Bit Stuffing
  169.  
  170.         In  order to assure that the flag bit sequence  mentioned 
  171. above  doesn't appear accidentally anywhere else in a frame,  the 
  172. sending  station  shall monitor the bit sequence for a  group  of 
  173. five  or more contiguous one bits.  Any time five contiguous  one 
  174. bits  are sent the sending station shall insert a zero bit  after 
  175. the  first  one  bit.   During frame  reception,  any  time  five 
  176. contiguous  one  bits  are  received,  a  zero  bit   immediately 
  177. following five one bits shall be discarded.
  178.  
  179. 2.2.7  Frame-Check Sequence
  180.  
  181.         The  frame-check sequence (FCS) is a  sixteen-bit  number 
  182. calculated  by  both the sender and receiver of a frame.   It  is 
  183. used  to  insure that the frame was not corrupted by  the  medium 
  184. used to get the frame from the sender to the receiver.  It  shall 
  185. be calculated in accordance with ISO 3309 (HDLC) Recommendations.
  186.  
  187. 2.2.8  Order of Bit Transmission
  188.  
  189.         With  the  exception of the FCS field, all fields  of  an 
  190. AX.25 frame shall be sent with each octet's least-significant bit 
  191. first.  The FCS shall be sent most-significant bit first.
  192.  
  193. 2.2.9  Invalid Frames
  194.  
  195.         Any frame consisting of less than 136 bits (including the 
  196. opening  and closing flags), not bounded by opening  and  closing 
  197. flags, or not octet aligned (an integral number of octets), shall 
  198. be  considered  an  invalid frame by the link  layer.   See  also 
  199. 2.4.4.4, below.
  200.  
  201. 2.2.10  Frame Abort
  202.  
  203.         If a frame must be prematurely aborted, at least  fifteen 
  204. contiguous ones shall be sent with no bit stuffing added.
  205.  
  206. 2.2.11  Interframe Time Fill
  207.  
  208.         Whenever   it  is  necessary  for  a  DXE  to  keep   its 
  209. transmitter  on  while  not actually  sending  frames,  the  time 
  210. between frames should be filled with contiguous flags.
  211.  
  212. 2.2.12  Link Channel States
  213.  
  214.         Not applicable.
  215.  
  216. 2.2.13  Address-Field Encoding
  217.  
  218.         The  address  field of all frames shall be  encoded  with 
  219. both the destination and source amateur call signs for the frame.  
  220. Except  for the Secondary Station Identifier (SSID), the  address 
  221. field  should  be made up of upper-case alpha and  numeric  ASCII 
  222. characters only.  If level 2 amateur "repeaters" are to be  used, 
  223. their call signs shall also be in the address field.
  224.  
  225.         The  HDLC address field is extended beyond one  octet  by 
  226. assigning  the  least-significant  bit of each  octet  to  be  an 
  227. "extension bit".  The extension bit of each octet is set to zero, 
  228. to indicate the next octet contains more address information,  or 
  229. one,  to  indicate  this is the last octet of  the  HDLC  address 
  230. field.   To make room for this extension bit, the  amateur  Radio 
  231. call sign information is shifted one bit left.
  232.  
  233. 2.2.13.1  Nonrepeater Address-Field Encoding
  234.  
  235.         If  level  2 repeaters are not being  used,  the  address 
  236. field is encoded as shown in Fig. 2.  The destination address  is 
  237. the call sign and SSID of the amateur radio station to which  the 
  238. frame is addressed, while the source address contains the amateur 
  239. call  sign  and SSID of the station that sent the  frame.   These 
  240. call signs are the call signs of the two ends of a level 2  AX.25 
  241. link only.
  242.  
  243.  
  244.  
  245.         First
  246.         Octet Sent
  247.  
  248.                      Address Field of Frame
  249.         Destination Address         Source Address
  250.         A1 A2 A3 A4 A5 A6 A7    A8 A9 A10 A11 A12 A13 A14
  251.  
  252.         Fig. 2 -- Nonrepeater Address-Field Encoding
  253.  
  254.  
  255.  
  256.         A1  through A14 are the fourteen octets that make up  the 
  257. two  address  subfields of the address  field.   The  destination 
  258. subaddress is seven octets long (A1 thru A7), and is sent  first.  
  259. This  address sequence provides the receivers of frames  time  to 
  260. check  the  destination address subfield to see if the  frame  is 
  261. addressed to them while the rest of the frame is being  received.  
  262. The  source  address subfield is then sent in octets  A8  through 
  263. A14.   Both  of these subfields are encoded in the  same  manner, 
  264. except  that  the last octet of the address field  has  the  HDLC 
  265. address extension bit set.
  266.  
  267.         There  is  an octet at the end of each  address  subfield 
  268. that contains the Secondary Station Identifier (SSID).  The  SSID 
  269. subfield  allows an Amateur Radio operator to have more than  one 
  270. packet-radio station operating under the same call sign.  This is 
  271. useful when an amateur wants to put up a repeater in addition  to 
  272. a regular station, for example.  The C bits (see 2.4.1.2,  below) 
  273. and H bit (see 2.2.13.2, below) are also contained in this octet, 
  274. along with two bits which are reserved for future use.
  275.  
  276.         Fig.  3A shows a typical AX.25 frame in  the  nonrepeater 
  277. mode of operation.
  278.  
  279.  
  280.  
  281.         Octet   ASCII   Bin.Data  Hex Data
  282.  
  283.         Flag            01111110     7E
  284.          A1       K     10010110     96
  285.          A2       8     01110000     70
  286.          A3       M     10011010     9A
  287.          A4       M     10011010     9A
  288.          A5       O     10011110     9E
  289.          A6     space   01000000     40
  290.          A7     SSID    11100000     E0
  291.          A8       W     10101110     AE
  292.          A9       B     10000100     84
  293.          A10      4     01100100     68
  294.          A11      J     10010100     94
  295.          A12      F     10001100     8C
  296.          A13      I     10010010     92
  297.          A14    SSID    01100001     61
  298.        Control    I     00111110     3E
  299.          PID    none    11110000     F0
  300.          FCS    part 1  XXXXXXXX     HH
  301.          FCS    part 2  XXXXXXXX     HH
  302.         Flag            01111110     7E
  303.  
  304.         Bit position    76543210
  305.  
  306.       Fig. 3A -- Nonrepeater AX.25 frame
  307.  
  308.  
  309.  
  310.         The frame shown is an I frame, not going through a  level 
  311. 2 repeater, from WB4JFI (SSID=0) to K8MMO (SSID=0), with no level 
  312. 3  protocol.   The P/F bit is set; the  receive  sequence  number 
  313. (N(R)) is 1; the send sequence number (N(S)) is 7.
  314.  
  315. 2.2.13.1.1  Destination Subfield Encoding
  316.  
  317.         Fig.  3 shows how an amateur call sign is placed  in  the 
  318. destination address subfield, occupying octets A1 thru A7.
  319.  
  320.  
  321.  
  322.              Octet   ASCII   Bin.Data   Hex Data
  323.  
  324.               A1       W     10101110      AE
  325.               A2       B     10000100      84
  326.               A3       4     01101000      68
  327.               A4       J     10010100      94
  328.               A5       F     10001100      8C
  329.               A6       I     10010010      92
  330.               A7     SSID    CRRSSID0
  331.  
  332.            Bit Position-->   76543210
  333.  
  334.           Fig. 3 -- Destination Field Encoding
  335.  
  336.  
  337.  
  338.         Where:
  339.  
  340.         1.  The top octet (A1) is the first octet sent, with  bit 
  341.             0  of each octet being the first bit sent, and bit  7 
  342.             being the last bit sent.
  343.  
  344.         2.  The  first (low-order or bit 0) bit of each octet  is 
  345.             the HDLC address extension bit, which is set to  zero 
  346.             on all but the last octet in the address field, where 
  347.             it is set to one.
  348.  
  349.        3.   The  bits marked "r" are reserved bits.  They may  be 
  350.             used in an agreed-upon manner in individual networks.  
  351.             When not implemented, they should be set to one.
  352.  
  353.         4.  The  bit marked "C" is used as  the  command/response 
  354.             bit of an AX.25 frame, as outlined in 2.4.1.2 below.
  355.  
  356.         5.  The  characters of the call sign should  be  standard 
  357.             seven-bit  ASCII  (upper  case only)  placed  in  the 
  358.             leftmost seven bits of the octet to make room for the 
  359.             address  extension  bit.  If the call  sign  contains 
  360.             fewer  than six characters, it should be padded  with 
  361.             ASCII spaces between the last call sign character and 
  362.             the SSID octet.
  363.  
  364.         6.  The  0000  SSID is reserved for  the  first  personal 
  365.             AX.25 station. This establishes one standard SSID for 
  366.             "normal" stations to use for the first station.
  367.  
  368. 2.2.13.2  Level 2 Repeater-Address Encoding
  369.  
  370.         If  a  frame  is to go through  level  2  amateur  packet 
  371. repeater(s), there is an additional address subfield appended  to 
  372. the end of the address field.  This additional subfield  contains 
  373. the call sign(s) of the repeater(s) to be used.  This allows more 
  374. than one repeater to share the same RF channel.  If this subfield 
  375. exists,  the  last octet of the source subfield has  its  address 
  376. extension  bit  set to zero, indicating that  more  address-field 
  377. data  follows.  The repeater-address subfield is encoded  in  the 
  378. same  manner  as the destination and  source  address  subfields, 
  379. except for the most-significant bit in the last octet, called the 
  380. "H" bit.  The H bit is used to indicate whether a frame has  been 
  381. repeated or not.
  382.  
  383.         In  order  to provide some method of  indicating  when  a 
  384. frame has been repeated, the H bit is set to zero on frames going 
  385. to  a repeater.  The repeater will set the H bit to one when  the 
  386. frame  is retransmitted.  Stations should monitor the H bit,  and 
  387. discard  any frames going to the repeater (uplink frames),  while 
  388. operating  through  a repeater.  Fig. 4 shows how  the  repeater- 
  389. address subfield is encoded.  Fig. 4A is an example of a complete 
  390. frame after being repeated.
  391.  
  392.  
  393.  
  394.                 Octet   ASCII   Bin.Data  Hex Data
  395.  
  396.                  A15      W     10101110     AE
  397.                  A16      B     10000100     84
  398.                  A17      4     01101000     68
  399.                  A18      J     10010100     94
  400.                  A19      F     10001100     8C
  401.                  A20      I     10010010     92
  402.                  A21    SSID    HRRSSID1
  403.  
  404.               Bit Order  -->    76543210
  405.  
  406.               Fig. 4 -- Repeater-address encoding
  407.  
  408.  
  409.  
  410.    Where:
  411.  
  412.    1.  The  top octet is the first octet sent, with bit  0  being 
  413.        sent first and bit 7 sent last of each octet.
  414.  
  415.    2.  As  with  the  source and  destination  address  subfields 
  416.        discussed  above, bit 0 of each octet is the HDLC  address 
  417.        extension  bit, which is set to zero on all but  the  last 
  418.        address octet, where it is set to one.
  419.  
  420.    3.  The  "R"  bits are reserved in the same manner as  in  the 
  421.        source and destination subfields.
  422.  
  423.    4.  The  "H" bit is the has-been-repeated bit.  It is  set  to 
  424.        zero  whenever a frame has not been repeated, and  set  to 
  425.        one by the repeater when the frame has been repeated.
  426.  
  427.  
  428.  
  429.         Octet    ASCII   Bin.Data  Hex Data
  430.  
  431.         Flag             01111110     7E
  432.          A1        K     10010110     96
  433.          A2        8     01110000     70
  434.          A3        M     10011010     9A
  435.          A4        M     10011010     9A
  436.          A5        O     10011110     9E
  437.          A6      space   01000000     40
  438.          A7      SSID    11100000     E0
  439.          A8        W     10101110     AE
  440.          A9        B     10000100     84
  441.          A10       4     01101000     68
  442.          A11       J     10010100     94
  443.          A12       F     10001100     8C
  444.          A13       I     10010010     92
  445.          A14     SSID    01100000     60
  446.          A15       W     10101110     AE
  447.          A16       B     10000100     84
  448.          A17       4     01101000     68
  449.          A18       J     10010100     94
  450.          A19       F     10001100     8C
  451.          A20       I     10010010     92
  452.          A21     SSID    11100011     E3
  453.        Control     I     00111110     3F
  454.          PID     none    11110000     F0
  455.          FCS     part 1  XXXXXXXX     HH
  456.          FCS     part 2  XXXXXXXX     HH
  457.         Flag             01111110     7E
  458.  
  459.         Bit position     76543210
  460.  
  461.       Fig. 4A -- AX.25 frame in repeater mode
  462.  
  463.  
  464.  
  465.         The  above frame is the same as Fig. 3A, except  for  the 
  466. addition of a repeater-address subfield (WB4JFI, SSID=1).  The  H 
  467. bit is set, indicating this is from the output of the repeater.
  468.  
  469. 2.2.13.3 Multiple Repeater Operation
  470.  
  471.         The  link-layer AX.25 protocol allows  operation  through 
  472. more  than  one  repeater, creating  a  primitive  frame  routing 
  473. mechanism.   Up to eight repeaters may be used by  extending  the 
  474. repeater-address subfield.  When there is more than one  repeater 
  475. address,  the repeater address immediately following  the  source 
  476. address  subfield  will be considered the address  of  the  first 
  477. repeater  of  a multiple-repeater chain.  As a  frame  progresses 
  478. through  a chain of repeaters, each successive repeater will  set 
  479. the  H bit (has-been-repeated bit) in its SSID octet,  indicating 
  480. that  the  frame has been successfully repeated through  it.   No 
  481. other  changes  to the frame are made (except for  the  necessary 
  482. recalculation of the FCS).  The destination station can determine 
  483. the  route  the frame took to each it by  examining  the  address 
  484. field.
  485.  
  486.         The  number of repeater addresses is variable.   All  but 
  487. the last repeater address will have the address extension bits of 
  488. all  octets  set to zero, as will all but the  last  octet  (SSID 
  489. octet) of the last repeater address.  The last octet of the  last 
  490. repeater address will have the address extension bit set to  one, 
  491. indicating the end of the address field.
  492.  
  493.         It should be noted that various timers (see 2.4.7, below) 
  494. may  have  to be adjusted to accommodate  the  additional  delays 
  495. encountered  when a frame must pass through  a  multiple-repeater 
  496. chain,  and  the return acknowledgement must travel  through  the 
  497. same path before reaching the source device.
  498.  
  499.         It  is anticipated that multiple-repeater operation is  a 
  500. temporary method of interconnecting stations over large distances 
  501. until  such  time that a layer 3 protocol is in use.   Once  this 
  502. layer 3 protocol becomes operational, repeater chaining should be 
  503. phased out.
  504.  
  505. 2.3  Elements of Procedure
  506.  
  507. 2.3.1  
  508.      The  elements of procedure are defined in terms  of  actions 
  509. that occur on receipt of frames.
  510.  
  511. 2.3.2  Control-Field Formats and State Variables
  512.  
  513. 2.3.2.1  Control-Field Formats
  514.  
  515.         The control field is responsible for identifying the type 
  516. of  frame  being sent, and is also used to  convey  commands  and 
  517. responses  from  one  end of the link to the other  in  order  to 
  518. maintain proper link control.
  519.  
  520.         The  control  fields  used in AX.25 use  the  CCITT  X.25 
  521. control fields for balanced operation (LAPB), with an  additional 
  522. control field taken from ADCCP to allow connectionless and round-
  523. table operation.
  524.  
  525.         There are three general types of AX.25 frames.  They  are 
  526. the Information frame (I frame), the Supervisory frame (S frame), 
  527. and  the  Unnumbered  frame (U frame).  Fig. 5  shows  the  basic 
  528. format  of  the  control field associated  with  these  types  of 
  529. frames.
  530.  
  531.  
  532.  
  533.               Control-Field      Control-Field Bits
  534.                   Type         7  6  5  4  3  2  1  0
  535.   
  536.                 I Frame          N(R)   P    N(S)   0
  537.                 S Frame          N(R)  P/F S  S  0  1
  538.                 U Frame        M  M  M P/F M  M  1  1
  539.  
  540.                   Fig. 5 -- Control-field formats
  541.  
  542.  
  543.  
  544.         Where:
  545.  
  546.         1.  Bit 0 is the first bit sent and bit 7 is the last bit 
  547.             sent of the control field.
  548.  
  549.         2.  N(S) is the send sequence number (bit 1 is the LSB).
  550.  
  551.         3.  N(R)  is  the receive sequence number (bit 5  is  the 
  552.             LSB).
  553.  
  554.         4.  The  "S" bits are the supervisory function bits,  and 
  555.             their encoding is discussed in 2.3.4.2.
  556.  
  557.         5.  The  "M" bits are the unnumbered frame modifier  bits 
  558.             and their encoding is discussed in 2.3.4.3.
  559.  
  560.         6.  The  P/F bit is the Poll/Final bit.  Its function  is 
  561.             described in 2.3.3.  The distinction between  command 
  562.             and response, and therefore the distinction between P 
  563.             bit and F bit, is made by addressing rules  discussed 
  564.             in 2.4.1.2.
  565.  
  566. 2.3.2.1.1  Information-Transfer Format
  567.  
  568.         All I frames have bit 0 of the control field set to zero.  
  569. N(S)  is  the sender's send sequence number  (the  send  sequence 
  570. number  of  this frame).  N(R) is the sender's  receive  sequence 
  571. number (the sequence number of the next expected received frame).  
  572. These numbers are described in 2.3.2.4.  In addition, the P/F bit 
  573. is to be used as described in 2.4.2.  
  574.  
  575.  
  576. 2.3.2.1.2  Supervisory Format
  577.  
  578.         Supervisory  frames  are denoted by having bit 0  of  the 
  579. control  field set to one, and bit 1 of the control field set  to 
  580. zero.   S  frames  provide  supervisory  link  control  such   as 
  581. acknowledging or requesting retransmission of I frames, and link-
  582. level window control.  Since S frames do not have an  information 
  583. field,  the  sender's send variable and  the  receiver's  receive 
  584. variable are not incremented for S frames.  In addition, the  P/F 
  585. bit is used as described in 2.4.2.
  586.  
  587. 2.3.2.1.3  Unnumbered Format
  588.  
  589.         Unnumbered frames are distinguished by having both bits 0 
  590. and 1 of the control field set to one.  U frames are  responsible 
  591. for  maintaining additional control over the link beyond what  is 
  592. accomplished  with  S  frames.  They  are  also  responsible  for 
  593. establishing  and  terminating link connections.  U  frames  also 
  594. allow  for the transmission and reception of information  outside 
  595. of   the  normal  flow  control.   Some  U  frames  may   contain 
  596. information and PID fields.  The P/F bit is used as described  in 
  597. 2.4.2.
  598.  
  599. 2.3.2.2  Control-Field Parameters
  600.  
  601. 2.3.2.3  Sequence Numbers
  602.  
  603.         Every  AX.25  I  frame shall be  assigned,  modulo  8,  a 
  604. sequential  number  from  0 to 7.  This will allow  up  to  seven 
  605. outstanding I frames per level 2 connection at a time.
  606.  
  607. 2.3.2.4  Frame Variables and Sequence Numbers
  608.  
  609. 2.3.2.4.1  Send State Variable V(S)
  610.  
  611.         The send state variable is a variable that is internal to 
  612. the  DXE  and  is never sent.  It contains  the  next  sequential 
  613. number  to  be assigned to the next transmitted  I  frame.   This 
  614. variable is updated upon the transmission of each I frame.
  615.  
  616. 2.3.2.4.2  Send Sequence Number N(S)
  617.  
  618.         The send sequence number is found in the control field of 
  619. all  I  frames.  It contains the sequence number of the  I  frame 
  620. being sent.  Just prior to the transmission of the I frame,  N(S) 
  621. is updated to equal the send state variable.
  622.   
  623.  
  624. 2.3.2.4.3 Receive State Variable V(R)
  625.  
  626.         The receive state variable is a variable that is internal 
  627. to the DXE.  It contains the sequence number of the next expected 
  628. received I frame.  This variable is updated upon the reception of 
  629. an  error-free  I  frame whose send sequence  number  equals  the 
  630. present received state variable value.
  631.  
  632. 2.3.2.4.4  Received Sequence Number N(R)
  633.  
  634.         The  received sequence number is in both I and S  frames.  
  635. Prior  to  sending an I or S frame, this variable is  updated  to 
  636. equal  that  of  the received  state  variable,  thus  implicitly 
  637. acknowledging  the  proper  reception of all  frames  up  to  and 
  638. including N(R)-1.
  639.  
  640. 2.3.3  Functions of Poll/Final (P/F) Bit
  641.  
  642.         The  P/F bit is used in all types of frames.  It is  used 
  643. in  a  command  (poll) mode to request an immediate  reply  to  a 
  644. frame.   The  reply  to this poll is  indicated  by  setting  the 
  645. response  (final)  bit  in  the  appropriate  frame.   Only   one 
  646. outstanding  poll condition per direction is allowed at  a  time.  
  647. The procedure for P/F bit operation is described in 2.4.2.
  648.  
  649. 2.3.4  Control Field Coding for Commands and Responses
  650.  
  651.         The following commands and responses, indicated by  their 
  652. control field encoding, are to be use by the DXE:
  653.  
  654. 2.3.4.1  Information Command Frame Control Field
  655.  
  656.         The  function  of  the  information  (I)  command  is  to 
  657. transfer   across  a  data  link  sequentially  numbered   frames 
  658. containing an information field.
  659.  
  660.         The  information-frame control field is encoded as  shown 
  661. in  Fig. 6.  These frames are sequentially numbered by  the  N(S) 
  662. subfield to maintain control of their passage over the link-layer 
  663. connection.
  664.  
  665.  
  666.  
  667.                           Control Field Bits
  668.                            7 6 5 4 3 2 1 0
  669.                             N(R) P  N(S) 0
  670.  
  671.                     Fig. 6 -- I frame control field
  672.  
  673.  
  674.  
  675. 2.3.4.2  Supervisory Frame Control Field
  676.  
  677.         The supervisory frame control fields are encoded as shown 
  678. in Fig. 7.
  679.  
  680.  
  681.  
  682.         Control Field Bits       7   6   5   4   3   2   1   0
  683.         Receive Ready     RR        N(R)    P/F  0   0   0   1
  684.         Receive Not Ready RNR       N(R)    P/F  0   1   0   1
  685.         Reject            REJ       N(R)    P/F  1   0   0   1
  686.  
  687.                 Fig. 7 -- S frame control fields
  688.  
  689.  
  690.                           The Frame identifiers:
  691.  
  692. C or SABM          Layer 2 Connect Request
  693. D or DISC          Layer 2 Disconnect Request
  694. I                  Information Frame
  695. RR                 Receive Ready. System Ready To Receive
  696. RNR or NR          Receive Not Ready. TNC Buffer Full
  697. RJ or REJ          Reject Frame. Out of Sequence or Duplicate
  698. FRMR               Frame Reject. Fatal Error
  699. UI                 Unnumbered Information Frame. "Unproto"
  700. DM                 Disconnect Mode. System Busy or Disconnected.
  701.  
  702.  
  703. 2.3.4.2.1  Receive Ready (RR) Command and Response
  704.  
  705.         Receive Ready is used to do the following:
  706.  
  707.    1.  to  indicate  that the sender of the RR is  now  able  to 
  708.        receive more I frames.
  709.  
  710.    2.  to  acknowledge  properly  received I frames  up  to,  and 
  711.        including N(R)-1, and
  712.  
  713.    3.  to clear a previously set busy condition created by an RNR 
  714.        command having been sent.
  715.  
  716.         The status of the DXE at the other end of the link can be 
  717. requested  by  sending a RR command frame with the P-bit  set  to 
  718. one.
  719.  
  720. 2.3.4.2.2  Receive Not Ready (RNR) Command and Response
  721.  
  722.         Receive Not Ready is used to indicate to the sender of  I 
  723. frames  that  the receiving DXE is temporarily  busy  and  cannot 
  724. accept any more I frames.  Frames up to N(R)-1 are  acknowledged.  
  725. Any I frames numbered N(R) and higher that might have been caught 
  726. between states and not acknowledged when the RNR command was sent 
  727. are not acknowledged.
  728.  
  729.         The RNR condition can be cleared by the sending of a  UA, 
  730. RR, REJ, or SABM frame.
  731.  
  732.         The status of the DXE at the other end of the link can be 
  733. requested  by sending a RNR command frame with the P bit  set  to 
  734. one.
  735.  
  736. 2.3.4.2.3  Reject (REJ) Command and Response
  737.  
  738.         The  reject frame is used to request retransmission of  I 
  739. frames  starting  with N(R).  Any frames that were  sent  with  a 
  740. sequence number of N(R)-1 or less are acknowledged.  Additional I 
  741. frames may be appended to the retransmission of the N(R) frame if 
  742. there are any.
  743.  
  744.         Only  one  reject  frame condition  is  allowed  in  each 
  745. direction  at  a time.  The reject condition is  cleared  by  the 
  746. proper  reception of I frames up to the I frame that  caused  the 
  747. reject condition to be initiated.
  748.  
  749.         The status of the DXE at the other end of the link can be 
  750. requested  by sending a REJ command frame with the P bit  set  to 
  751. one.
  752.  
  753. 2.3.4.3  Unnumbered Frame Control Fields
  754.  
  755.         Unnumbered  frame control fields are either  commands  or 
  756. responses.
  757.  
  758.         Fig.  8 shows the layout of U frames  implemented  within 
  759. this protocol.
  760.  
  761.  
  762.  
  763.         Control Field                Type     Control Field Bits
  764.                                             7  6  5  4  3  2  1  0
  765.  
  766. Set Asynchronous Balanced Mode-SABM  Cmd    0  0  1  P  1  1  1  1
  767. Disconnect-DISC                      Cmd    0  1  0  P  0  0  1  1
  768. Disconnected Mode-DM                 Res    0  0  0  F  1  1  1  1
  769. Unnumbered Acknowledge-UA            Res    0  1  1  F  0  0  1  1
  770. Frame Reject-FRMR                    Res    1  0  0  F  0  1  1  1
  771. Unnumbered Information-UI           Either  0  0  0 P/F 0  0  1  1
  772.  
  773.                 Fig. 8 -- U frame control fields
  774.  
  775.  
  776.  
  777. 2.3.4.3.1  Set Asynchronous Balanced Mode (SABM) Command
  778.  
  779.         The  SABM  command  is  used  to  place  2  DXEs  in  the 
  780. asynchronous balanced mode.  This is a balanced mode of operation 
  781. known as LAPB where both devices are treated as equals.
  782.  
  783.         Information fields are not allowed in SABM commands.  Any 
  784. outstanding  I frames left when the SABM command is  issued  will 
  785. remain unacknowledged.
  786.  
  787.         The  DXE  confirms  reception and acceptance  of  a  SABM 
  788. command   by  sending  a  UA  response  frame  at  the   earliest 
  789. opportunity.   If  the  DXE is not capable of  accepting  a  SABM 
  790. command, it should respond with a DM frame if possible.
  791.  
  792. 2.3.4.3.2  Disconnect (DISC) Command
  793.  
  794.         The  DISC  command is used to terminate  a  link  session 
  795. between  two  stations.  No information field is permitted  in  a 
  796. DISC command frame.
  797.  
  798.         Prior  to  acting on the DISC frame,  the  receiving  DXE 
  799. confirms acceptance of the DISC by issuing a UA response frame at 
  800. its  earliest opportunity.  The DXE sending the DISC  enters  the 
  801. disconnected state when it receives the UA response.
  802.  
  803.         Any  unacknowledged  I frames left when this  command  is 
  804. acted upon will remain unacknowledged.
  805.  
  806. 2.3.4.3.3  Frame Reject (FRMR) Response
  807.  
  808. 2.3.4.3.3.1  
  809.      The FRMR response frame is sent to report that the  receiver 
  810. of  a frame cannot successfully process that frame and  that  the 
  811. error condition is not correctable by sending the offending frame 
  812. again.  Typically this condition will appear when a frame without 
  813. an  FCS  error  has  been received  with  one  of  the  following 
  814. conditions:
  815.  
  816.  1.  The  reception of an invalid or not implemented  command  or 
  817.      response frame.
  818.  
  819.  2.  The reception of an I frame whose information field  exceeds 
  820.      the agreed-upon length.  (See 2.4.7.3, below.)
  821.  
  822.  3.  The  reception  of an improper N(R).  This  usually  happens 
  823.      when the N(R) frame has already been sent and  acknowledged, 
  824.      or when N(R) is out of sequence with what was expected.
  825.  
  826.  4.  The reception of a frame with an information field where one 
  827.      is  not  allowed, or the reception of a U or S  frame  whose 
  828.      length is incorrect.  Bits W and Y described in  2.3.4.3.3.2 
  829.      should both be set to one to indicate this condition.
  830.  
  831.       5.  The reception of a supervisory frame with the F bit set 
  832.      to  one,  except  during a  timer  recovery  condition  (see 
  833.      2.4.4.9), or except as a reply to a command frame sent  with 
  834.      the  P  bit  set to one. Bit W  (described  in  2.3.4.3.3.2) 
  835.      should be set to one.
  836.  
  837.  6.  The reception of an unexpected UA or DM response frame.  Bit 
  838.      W should be set to one.
  839.  
  840.  7.  The reception of a frame with an invalid N(S).  Bit W should be
  841.      set to one.
  842.  
  843.         An  invalid N(R) is defined as one which points to  an  I 
  844. frame  that previously has been transmitted and acknowledged,  or 
  845. an  I  frame which has not been transmitted and is not  the  next 
  846. sequential I frame pending transmission.
  847.   
  848.         An  invalid N(S) is defined as an N(S) that is  equal  to 
  849. the  last transmitted N(R)+k and is equal to the  received  state 
  850. variable  V(R),  where  k is the maximum  number  of  outstanding 
  851. information frames as defined in 2.4.7.4 below.
  852.  
  853.         An  invalid  or not implemented command  or  response  is 
  854. defined  as a frame with a control field that is unknown  to  the 
  855. receiver of this frame.
  856.  
  857. 2.3.4.3.3.2  
  858.      When a FRMR frame is sent, an information field is added  to 
  859. the  frame that contains additional information indicating  where 
  860. the  problem  occurred.  This information field is  three  octets 
  861. long and is shown in Fig. 9.
  862.  
  863.  
  864.  
  865.                      Information Field Bits
  866.  23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
  867.   0  0  0  0  Z  Y  X  W   V(R)    C   V(S)  0  Rejected Frame 
  868.                                    R            Control Field
  869.  
  870.              Fig. 9 -- FRMR frame information field
  871.  
  872.  
  873.  
  874.   Where:
  875.  
  876.   1.  The rejected frame control field carries the control  field 
  877.       of  the frame that caused the reject condition.  It  is  in 
  878.       bits 0-7 of the information field.
  879.  
  880.   2.  V(S)  is  the  current send state variable  of  the  device 
  881.       reporting the rejection (bit 9 is the low bit).
  882.  
  883.   3.  The  CR bit is set to zero to indicate the  rejected  frame 
  884.       was a command, or one if it was a response.
  885.  
  886.   4.  V(R)  is the current receive state variable of  the  device 
  887.       reporting rejection (bit 13 is the low bit).
  888.  
  889.   5.  If W is set to 1, the control field received was invalid or 
  890.       not implemented.
  891.  
  892.   6.  If  X  is  set  to 1, the  frame  that  caused  the  reject 
  893.       condition  was considered invalid because it was a U  or  S 
  894.       frame  that had an information field that is  not  allowed.  
  895.       Bit W must be set to 1 in addition to the X bit.
  896.  
  897.   7.  If  Y is set to 1, the control field received and  returned 
  898.       in   bits   exceeded  the  maximum   allowed   under   this 
  899.       recommendation in 2.4.7.3, below.
  900.  
  901.   8.  If  A is set to 1, the control field received and  returned 
  902.       in bits 1 to 8 contained an invalid N(R).
  903.  
  904.   9.  Bits 8, and 20 to 23 are set to 0.
  905.  
  906.  
  907. 2.3.4.3.4  Unnumbered Acknowledge (UA) Response
  908.  
  909.         The  UA  response  frame  is  sent  to  acknowledge   the 
  910. reception  and  acceptance of a SABM or DISC  command  frame.   A 
  911. received command is not actually processed until the UA  response 
  912. frame  is  sent.  Information fields are not permitted  in  a  UA 
  913. frame.
  914.  
  915. 2.3.4.3.5  Disconnected Mode (DM) Response
  916.  
  917.         The  disconnected  mode response is sent whenever  a  DXE 
  918. receives  a  frame  other  than a SABM or UI  frame  while  in  a 
  919. disconnected  mode.   It  is  also sent to  request  a  set  mode 
  920. command,  or  to indicate it cannot accept a  connection  at  the 
  921. moment.  The DM response does not have an information field.
  922.  
  923.         Whenever a SABM frame is a received, and it is determined 
  924. that  a  connection is not possible, a DM frame  shall  be  sent.  
  925. This  will  indicate  that the called  station  cannot  accept  a 
  926. connection at that time.
  927.  
  928.         While a DXE is in the disconnected mode, it will  respond 
  929. to  any command other than a SABM or UI frame with a DM  response 
  930. with the P/F bit set to 1.
  931.  
  932. 2.3.4.3.6  Unnumbered Information (UI) Frame
  933.  
  934.         The   Unnumbered  Information  frame  contains  PID   and 
  935. information fields and is used to pass information along the link 
  936. outside the normal information controls.  This allows information 
  937. fields  to go back and forth on the link bypassing flow  control.  
  938. Since   these  frames  are  not  acknowledgeable,  if  one   gets 
  939. obliterated, there is no way to recover it.  A received UI  frame 
  940. with  the  P bit set shall cause a response  to  be  transmitted.  
  941. This response shall be a DM frame when in the disconnected  state 
  942. or  a  RR  (or  RNR, if appropriate)  frame  in  the  information 
  943. transfer state.
  944.  
  945. 2.3.5  Link Error Reporting and Recovery
  946.  
  947.         There are several link-layer errors that are  recoverable 
  948. without  terminating the connection.  These error situations  may 
  949. occur  as  a  result  of  malfunctions  within  the  DXE,  or  if 
  950. transmission errors occur.
  951.  
  952. 2.3.5.1  DXE Busy Condition
  953.  
  954.         When  a  DXE  becomes temporarily  unable  to  receive  I 
  955. frames,  such  as when receive buffers are full, it will  send  a 
  956. Receive Not Ready (RNR) frame.  This informs the other DXE   that 
  957. this  DXE  cannot handle any more I frames at the  moment.   This 
  958. condition is usually cleared by the sending of a UA, RR, REJ,  or 
  959. SABM command frame.
  960.  
  961. 2.3.5.2  Send Sequence Number Error
  962.  
  963.         If the send sequence number, N(S), of an otherwise error-
  964. free  received frame does not match the receive  state  variable, 
  965. V(R),  a  send sequence error has occurred, and  the  information 
  966. field will be discarded.  The receiver will not acknowledge  this 
  967. frame, or any other I frames, until N(S) matches V(R).  
  968.  
  969.         The  control  field of the erroneous I frame(s)  will  be 
  970. accepted so that link supervisory functions such as checking  the 
  971. P/F  bit can still be performed.  Because of this  updating,  the 
  972. retransmitted I frame may have an updated P bit and N(R).
  973.  
  974. 2.3.5.3  Reject (REJ) Recovery
  975.  
  976.         REJ  is  used  to request a retransmission  of  I  frames 
  977. following  the  detection  of a N(S) sequence  error.   Only  one 
  978. outstanding  "sent  REJ" condition is allowed at  a  time.   This 
  979. condition  is  cleared  when  the  requested  I  frame  has  been 
  980. received.
  981.  
  982.         A DXE receiving the REJ command will clear the  condition 
  983. by  resending all outstanding I frames (up to the  window  size), 
  984. starting with the one indicated in N(R) of the REJ frame.
  985.  
  986. 2.3.5.4  Time-out Error Recovery
  987.  
  988. 2.3.5.4.1  T1 Timer Recovery
  989.  
  990.         If  a DXE, due to a transmission error, does not  receive 
  991. (or  receives and discards) a single I frame or the last I  frame 
  992. in  a sequence of I frames, it will not detect  a  send-sequence-
  993. number  error,  and therefore will not transmit a REJ.   The  DXE 
  994. which transmitted the unacknowledged I frame(s) shall,  following 
  995. the  completion of time-out period T1, take appropriate  recovery 
  996. action  to determine when I frame retransmission should begin  as 
  997. described  in 2.4.4.9, below.  This condition is cleared  by  the 
  998. reception of an acknowledgement for the sent frame(s), or by  the 
  999. link being reset.  See 2.4.6.
  1000.  
  1001. 2.3.5.4.2  Timer T3 Recovery
  1002.  
  1003.         Timer  T3 is used to assure the link is still  functional 
  1004. during  periods of low information transfer.  Whenever T1 is  not 
  1005. running  (no  outstanding I frames), T3 is used  to  periodically 
  1006. poll  the  other DXE of a link.  When T3 times out, a RR  or  RNR 
  1007. frame  is transmitted as a command and with the P bit  set.   The 
  1008. waiting  acknowledgement  procedure  (2.4.4.9,  below)  is   then 
  1009. executed.
  1010.  
  1011. 2.3.5.5  Invalid Frame or FCS Error
  1012.  
  1013.         If  an invalid frame is received, or a frame is  received 
  1014. with  an FCS error, that frame will be discarded with  no  action 
  1015. taken.
  1016.  
  1017. 2.3.5.6  Frame Rejection Condition
  1018.  
  1019.         A  frame  rejection condition occurs  when  an  otherwise 
  1020. error-free  frame  has been received with one of  the  conditions 
  1021. listed in 2.3.4.3.3 above.
  1022.  
  1023.         Once  a  rejection  error occurs, no more  I  frames  are 
  1024. accepted  (except for the examination of the P/F bit)  until  the 
  1025. error is resolved.  The error condition is reported to the  other 
  1026. DXE by sending a FRMR response frame.  See 2.4.5.
  1027.  
  1028. 2.4  Description of AX.25 Procedures
  1029.  
  1030.         The  following  describes the procedures used  to  setup, 
  1031. use, and disconnect a balanced link between two DXE stations.
  1032.  
  1033. 2.4.1  Address Field Operation
  1034.  
  1035. 2.4.1.1  Address Information
  1036.  
  1037.         All   transmitted  frames  shall  have   address   fields 
  1038. conforming  to  2.2.13, above.  All frames shall  have  both  the 
  1039. destination device and the source device addresses in the address 
  1040. field,  with the destination address coming first.   This  allows 
  1041. many links to share the same RF channel.  The destination address 
  1042. is  always  the address of the station(s) to receive  the  frame, 
  1043. while the source address contains the address of the device  that 
  1044. sent the frame.
  1045.  
  1046.         The destination address can be a group name or club  call 
  1047. sign if the point-to-multipoint operation is allowed.   Operation 
  1048. with  destination addresses other than actual amateur call  signs 
  1049. is a subject for further study.
  1050.  
  1051. 2.4.1.2  Command/Response Procedure
  1052.  
  1053.         AX.25  Version 2.0 has implemented  the  command/response 
  1054. information   in  the  address  field.   In  order  to   maintain 
  1055. compatibility    with   previous   versions   of    AX.25,    the 
  1056. command/response information is conveyed using two bits.
  1057.  
  1058.         An  upward-compatible AX.25 DXE can determine whether  it 
  1059. is  communicating  with  a DXE using an  older  version  of  this 
  1060. protocol by testing the command/response bit information  located 
  1061. in  bit 7 of the SSID octets of both the destination  and  source 
  1062. address subfields.  If both C bits are set to zero, the device is 
  1063. using  the  older protocol.  The newer version  of  the  protocol 
  1064. always has one of these two bits set to one and the other set  to 
  1065. zero, depending on whether the frame is a command or a response.
  1066.  
  1067.         The  command/response  information is  encoded  into  the 
  1068. address field as shown in Fig. 10.
  1069.  
  1070.  
  1071.  
  1072.    Frame Type          Dest. SSID C-Bit    Source SSID C-Bit
  1073.  
  1074.   Previous versions             0                    0
  1075.   Command (V.2.0)               1                    0
  1076.   Response (V.2.0)              0                    1
  1077.   Previous versions             1                    1
  1078.  
  1079.               Fig. 10 -- Command/Response encoding
  1080.  
  1081.  
  1082.  
  1083.         Since  all  frames  are  considered  either  commands  or 
  1084. responses, a device shall always have one of the bits set to one, 
  1085. and the other bit set to zero.
  1086.  
  1087.         The  use  of the command/response  information  in  AX.25 
  1088. allows  S frames to be either commands or responses.   This  aids 
  1089. maintenance   of  proper  control  over  the  link   during   the 
  1090. information transfer state.
  1091.  
  1092. 2.4.2  P/F Bit Procedures
  1093.  
  1094.         The next response frame returned by the DXE to a SABM  or 
  1095. DISC command with the P bit set to 1 will be a UA or DM  response 
  1096. with the F bit set to 1.  
  1097.  
  1098.         The next response frame returned to an I frame with the P 
  1099. bit  set  to 1, received during the information  transfer  state, 
  1100. will be a RR, RNR, or REJ response with the F bit set to 1.
  1101.  
  1102.         The next response frame returned to a supervisory command 
  1103. frame  with the P bit set to 1, received during  the  information 
  1104. transfer state, will be a RR, RNR, or REJ response frame with the 
  1105. F bit set to 1.
  1106.  
  1107.         The  next  response frame returned to a S  or  I  command 
  1108. frame  with  the  P bit set to 1, received  in  the  disconnected 
  1109. state, will be a DM response frame with the F bit set to 1.
  1110.  
  1111.         The  P  bit  is used in  conjunction  with  the  time-out 
  1112. recovery condition discussed in 2.3.5.4, above.
  1113.  
  1114.         When not used, the P/F bit is set to zero.
  1115.  
  1116. 2.4.3  Procedures For Link Set-Up and Disconnection
  1117.  
  1118. 2.4.3.1  LAPB Link Connection Establishment
  1119.  
  1120.         When  one DXE wishes to connect to another DXE,  it  will 
  1121. send  a SABM command frame to that device and start  timer  (T1).  
  1122. If  the other DXE is there and able to connect, it  will  respond 
  1123. with  a UA response frame, and reset both of its  internal  state 
  1124. variables  (V(S)  and V(R)).  The reception of  the  UA  response 
  1125. frame  at  the  other  end will  cause  the  DXE  requesting  the 
  1126. connection  to  cancel the T1 timer and set  its  internal  state 
  1127. variables to 0.
  1128.  
  1129.         If the other DXE doesn't respond before T1 times out, the 
  1130. device requesting the connection will re-send the SABM frame, and 
  1131. start  T1  running  again.  The DXE should  continue  to  try  to 
  1132. establish  a  connection  until it has  tried  unsuccessfully  N2 
  1133. times.  N2 is defined in 2.4.7.2, below.
  1134.  
  1135.         If,  upon  reception of a SABM command, the  DXE  decides 
  1136. that  it  cannot enter the indicated state, it should send  a  DM 
  1137. frame.
  1138.  
  1139.         When  receiving a DM response, the DXE sending  the  SABM 
  1140. should  cancel  its  T1 timer, and  not  enter  the  information-
  1141. transfer state.  
  1142.  
  1143.         The  DXE sending a SABM command will ignore  and  discard 
  1144. any  frames except SABM, DISC, UA, and DM frames from  the  other 
  1145. DXE.
  1146.  
  1147.         Frames  other  than UA and DM in response to  a  received 
  1148. SABM  will  be  sent  only after the link is set  up  and  if  no 
  1149. outstanding SABM exists.
  1150.  
  1151. 2.4.3.2  Information-Transfer Phase
  1152.  
  1153.         After establishing a link connection, the DXE will  enter 
  1154. the  information-transfer  state.  In this state,  the  DXE  will 
  1155. accept  and  transmit I and S frames according to  the  procedure 
  1156. outlined in 2.4.4, below.
  1157.  
  1158.         When  receiving a SABM command while in the  information-
  1159. transfer  state,  the  DXE will follow  the  resetting  procedure 
  1160. outlined in 2.4.6 below.
  1161.  
  1162. 2.4.3.3  Link Disconnection
  1163.  
  1164. 2.4.3.3.1  
  1165.      While  in  the information-transfer state,  either  DXE  may 
  1166. indicate a request to disconnect the link by transmitting a  DISC 
  1167. command frame and starting timer T1 (see 2.4.7).
  1168.  
  1169. 2.4.3.3.2  
  1170.      A DXE, upon receiving a valid DISC command, shall send a  UA 
  1171. response  frame  and enter the disconnected state.  A  DXE,  upon 
  1172. receiving  a  UA  or DM response to a sent  DISC  command,  shall 
  1173. cancel timer T1, and enter the disconnected state.
  1174.  
  1175. 2.4.3.3.3  
  1176.      If  a UA or DM response is not correctly received before  T1 
  1177. times out, the DISC frame should be sent again and T1  restarted.  
  1178. If  this happens N2 times, the DXE should enter the  disconnected 
  1179. state.
  1180.  
  1181. 2.4.3.4  Disconnected State
  1182.  
  1183. 2.4.3.4.1  
  1184.      A  DXE  in  the disconnected state  shall  monitor  received 
  1185. commands  and react upon the reception of a SABM as described  in 
  1186. 2.4.3.1 above and will transmit a DM frame in response to a  DISC 
  1187. command.
  1188.  
  1189. 2.4.3.4.2  
  1190.      In the disconnected state, a DXE may initiate a link  set-up 
  1191. as outlined in connection establishment above (2.4.3.1).  It  may 
  1192. also  respond  to  the  reception  of  a  SABM  and  establish  a 
  1193. connection, or it may ignore the SABM and send a DM instead.
  1194.  
  1195. 2.4.3.4.3  
  1196.      Any  DXE receiving a command frame other than a SABM  or  UI 
  1197. frame  with the P bit set to one should respond with a  DM  frame 
  1198. with  the  F  bit  set to one.  The  offending  frame  should  be 
  1199. ignored.
  1200.  
  1201. 2.4.3.4.4  
  1202.      When  the DXE enters the disconnected state after  an  error 
  1203. condition  or if an internal error has resulted in the DXE  being 
  1204. in  the  disconnected  state, the DXE  should  indicate  this  by 
  1205. sending  a  DM response rather than a DISC frame and  follow  the 
  1206. link  disconnection procedure outlined in 2.4.3.3.3, above.   The 
  1207. DXE  may then try to re-establish the link using the link  set-up 
  1208. procedure outlined in 2.4.3.1, above.
  1209.  
  1210. 2.4.3.5  Collision Recovery
  1211.  
  1212. 2.4.3.5.1  Collisions in a Half-Duplex Environment
  1213.  
  1214.         Collisions  of  frames in a half-duplex  environment  are 
  1215. taken  care  of  by  the  retry  nature  of  the  T1  timer   and 
  1216. retransmission count variable.  No other special action needs  to 
  1217. be taken.
  1218.  
  1219. 2.4.3.5.2  Collisions of Unnumbered Commands
  1220.  
  1221.         If sent and received SABM or DISC command frames are  the 
  1222. same,  both  DXEs  should  send a UA  response  at  the  earliest 
  1223. opportunity, and both devices should enter the indicated state.
  1224.  
  1225.         If sent and received SABM or DISC commands are different, 
  1226. both  DXEs should enter the disconnected state and transmit a  DM 
  1227. frame at the earliest opportunity.
  1228.  
  1229. 2.4.3.5.3  Collision of a DM with a SABM or DISC
  1230.  
  1231.         When  an  unsolicited  DM  response  frame  is  sent,   a 
  1232. collision  between it and a SABM or DISC may occur.  In order  to 
  1233. prevent  this  DM from being misinterpreted, all  unsolicited  DM 
  1234. frames  should  be transmitted with the F bit set to  zero.   All 
  1235. SABM  and DISC frames should be sent with the P bit set  to  one.  
  1236. This will prevent any confusion when a DM frame is received.
  1237.  
  1238. 2.4.3.6  Connectionless Operation
  1239.  
  1240.         In  Amateur  Radio,  there  is  an  additional  type   of 
  1241. operation  that is not feasible using level 2 connections.   This 
  1242. operation  is  the  round table, where several  amateurs  may  be 
  1243. engaged  in one conversation.  This type of operation  cannot  be 
  1244. accommodated by AX.25 link-layer connections.
  1245.  
  1246.         The   way   round-table  activity   is   implemented   is 
  1247. technically  outside  the AX.25 connection, but still  using  the 
  1248. AX.25 frame structure.
  1249.  
  1250.         AX.25 uses a special frame for this operation, called the 
  1251. Unnumbered  Information (UI) frame.  When this type of  operation 
  1252. is  used,  the  destination  address  should  have  a  code  word 
  1253. installed  in  it to prevent the users of that  particular  round 
  1254. table from seeing all frames going through the shared RF  medium.  
  1255. An example of this is if a group of amateurs are in a round-table 
  1256. discussion  about  packet  radio, they could put  PACKET  in  the 
  1257. destination  address,  so  they would receive  frames  only  from 
  1258. others in the same discussion.  An added advantage of the use  of 
  1259. AX.25  in this manner is that the source of each frame is in  the 
  1260. source  address  subfield,  so  software  could  be  written   to 
  1261. automatically display who is making what comments.
  1262.  
  1263.         Since  this  mode  is connectionless, there  will  be  no 
  1264. requests for retransmissions of bad frames.  Collisions will also 
  1265. occur, with the potential of losing the frames that collided.
  1266.  
  1267. 2.4.4  Procedures for Information Transfer
  1268.  
  1269.         Once  a  connection  has been  established,  as  outlined 
  1270. above, both devices are able to accept I, S, and U frames.
  1271.  
  1272. 2.4.4.1  Sending I Frames
  1273.  
  1274.         Whenever  a DXE has an I frame to transmit, it will  send 
  1275. the  I frame with N(S) of the control field equal to its  current 
  1276. send  state  variable V(S).  Once the I frame is sent,  the  send 
  1277. state  variable  is  incremented  by one.  If  timer  T1  is  not 
  1278. running, it should be started.  If timer T1 is running, it should 
  1279. be restarted.
  1280.  
  1281.         The DXE should not transmit any more I frames if its send 
  1282. state variable equals the last received N(R) from the other  side 
  1283. of  the link plus seven.  If it were to send more I  frames,  the 
  1284. flow control window would be exceed, and errors could result.
  1285.  
  1286.         If  a  DXE is in a busy condition, it may  still  send  I 
  1287. frames as long as the other device is not also busy.
  1288.  
  1289.         If  a  DXE is in the frame-rejection mode, it  will  stop 
  1290. sending I frames.
  1291.  
  1292. 2.4.4.2  Receiving I Frames
  1293.  
  1294. 2.4.4.2.1  
  1295.      If  a DXE receives a valid I frame (one with a  correct  FCS 
  1296. and  whose  send sequence number equals  the  receiver's  receive 
  1297. state variable) and is not in the busy condition, it will  accept 
  1298. the  received I frame, increment its receive state variable,  and 
  1299. act in one of the following manners:
  1300.         
  1301.  1.  If it has an I frame to send, that I frame may be sent with the
  1302.      transmitted N(R) equal to its receive state variable V(R) (thus
  1303.      acknowledging the received frame).  Alternately, the device may
  1304.      send a RR frame with N(R) equal to V(R), and then send the I 
  1305.      frame.
  1306.  
  1307.  2.  If there are no outstanding I frames, the receiving device will
  1308.      send a RR frame with N(R) equal to V(R).  The receiving DXE may
  1309.      wait a small period of time before sending the RR frame to be sure
  1310.      additional I frames are not being transmitted.
  1311.  
  1312. 2.4.4.2.2      
  1313.      If  the  DXE  is  in a busy condition,  it  may  ignore  any 
  1314. received  I  frames without reporting this condition  other  than 
  1315. repeating the indication of the busy condition.
  1316.  
  1317.         If  a busy condition exists, the DXE receiving  the  busy 
  1318. condition   indication  should  poll  the  sender  of  the   busy 
  1319. indication periodically until the busy condition disappears.  
  1320.  
  1321.         A  DXE may poll the busy DXE periodically with RR or  RNR 
  1322. frames with the P bit set to one.
  1323.  
  1324.         The  reception  of  I  frames  that  contain  zero-length 
  1325. information  fields  shall be reported to the next level  but  no 
  1326. information field will be transferred.
  1327.  
  1328. 2.4.4.3  Reception of Out of Sequence Frames
  1329.  
  1330.         When  an I frame is received with a correct FCS, but  its 
  1331. send sequence number, N(S), does not match the current receiver's 
  1332. receive  state  variable, the frame should be discarded.   A  REJ 
  1333. frame  shall be sent with a receive sequence number equal to  one 
  1334. higher (modulo 8) than the last correctly received I frame if  an 
  1335. uncleared  N(S) sequence error condition has not been  previously 
  1336. established.   The  received state variable and poll bit  of  the 
  1337. discarded  frame should be checked and acted upon, if  necessary, 
  1338. before discarding the frame.  
  1339.  
  1340. 2.4.4.4  Reception of Incorrect Frames
  1341.  
  1342.         When  a  DXE receives a frame with an incorrect  FCS,  an 
  1343. invalid  frame, or a frame with an improper address,  that  frame 
  1344. shall be discarded.
  1345.  
  1346. 2.4.4.5  Receiving Acknowledgement
  1347.  
  1348.         Whenever an I or S frame is correctly received, even in a 
  1349. busy condition, the N(R) of the received frame should be  checked 
  1350. to  see if it includes an acknowledgement of outstanding  sent  I 
  1351. frames.   The T1 timer should be cancelled if the received  frame 
  1352. actually  acknowledges previously unacknowledged frames.  If  the 
  1353. T1  timer is cancelled and there are still some frames that  have 
  1354. been sent that are not acknowledged, T1 should be started  again.  
  1355. If  the T1 timer runs out before an acknowledgement is  received, 
  1356. the  device  should proceed to the  retransmission  procedure  in 
  1357. 2.4.4.9.
  1358.  
  1359. 2.4.4.6  Receiving Reject
  1360.  
  1361.         Upon receiving a REJ frame, the transmitting DXE will set 
  1362. its  send  state variable to the same value as  the  REJ  frame's 
  1363. received sequence number in the control field.  The DXE will then 
  1364. retransmit  any  I  frame(s) outstanding at  the  next  available 
  1365. opportunity conforming to the following:
  1366.  
  1367.  1.  If the DXE is not transmitting at the time, and the  channel 
  1368.      is  open,  the  device  may commence  to  retransmit  the  I 
  1369.      frame(s) immediately.
  1370.  
  1371.  2.  If   the   DXE  is  operating  on  a   full-duplex   channel 
  1372.      transmitting  a UI or S frame when it receives a REJ  frame, 
  1373.      it may finish sending the UI or S frame and then  retransmit 
  1374.      the I frame(s).
  1375.  
  1376.  3.  If   the   DXE  is  operating  in  a   full-duplex   channel 
  1377.      transmitting  another I frame when it receives a REJ  frame, 
  1378.      it  may  abort  the  I  frame  it  was  sending  and   start 
  1379.      retransmission of the requested I frames immediately.
  1380.  
  1381.  4.  The DXE may send just the one I frame outstanding, or it may 
  1382.      send  more than the one indicated if more I frames  followed 
  1383.      the  first  one not acknowledged, provided the total  to  be 
  1384.      sent does not exceed the flow-control window (7 frames).
  1385.  
  1386.         If the DXE receives a REJ frame with the poll bit set, it 
  1387. should  respond with either a RR or RNR frame with the final  bit 
  1388. set before retransmitting the outstanding I frame(s).
  1389.  
  1390. 2.4.4.7  Receiving a RNR Frame
  1391.  
  1392.         Whenever  a  DXE  receives a RNR  frame,  it  shall  stop 
  1393. transmission  of  I  frames until the  busy  condition  has  been 
  1394. cleared.   If timer T1 runs out after the RNR was  received,  the 
  1395. waiting  acknowledgement  procedure  listed  in  2.4.4.9,  below, 
  1396. should  be  performed.  The poll bit may be used  in  conjunction 
  1397. with  S  frames  to test for a change in  the  condition  of  the 
  1398. busied-out DXE.
  1399.  
  1400. 2.4.4.8  Sending a Busy Indication
  1401.  
  1402.         Whenever a DXE enters a busy condition, it will  indicate 
  1403. this  by sending a RNR response at the next  opportunity.   While 
  1404. the  DXE is in the busy condition, it may receive and  process  S 
  1405. frames,  and if a received S frame has the P bit set to one,  the 
  1406. DXE should send a RNR frame with the F bit set to one at the next 
  1407. possible  opportunity.   To  clear the busy  condition,  the  DXE 
  1408. should  send either a RR or REJ frame with the received  sequence 
  1409. number equal to the current receive state variable, depending  on 
  1410. whether the last received I frame was properly received or not.
  1411.  
  1412. 2.4.4.9  Waiting Acknowledgement
  1413.  
  1414.         If timer T1 runs out waiting the acknowledgement from the 
  1415. other DXE for an I frame transmitted, the DXE will restart  timer 
  1416. T1  and transmit an appropriate supervisory command frame (RR  or 
  1417. RNR)  with  the  P  bit set.  If the  DXE  receives  correctly  a 
  1418. supervisory  response frame with the F bit set and with  an  N(R) 
  1419. within  the  range from the last N(R) received to the  last  N(S) 
  1420. sent  plus  one, the DXE will restart timer T1 and will  set  its 
  1421. send  state  variable  V(S) to the received N(R).   It  may  then 
  1422. resume   with   I  frame  transmission  or   retransmission,   as 
  1423. appropriate.  If, on the other hand, the DXE receives correctly a 
  1424. supervisory response frame with the F bit not set, or an I  frame 
  1425. or  supervisory command frame, and with an N(R) within the  range 
  1426. from  the last N(R) received to the last N(S) sent plus one,  the 
  1427. DXE will not restart timer T1, but will use the received N(R)  as 
  1428. an  indication of acknowledgement of transmitted I frames  up  to 
  1429. and including I frame numbered N(R)-1.
  1430.  
  1431.         If timer T1 runs out before a supervisory response  frame 
  1432. with  the  F  bit set is received, the  DXE  will  retransmit  an 
  1433. appropriate supervisory command frame (RR or RNR) with the P  bit 
  1434. set.  After N2 attempts to get a supervisory response frame  with 
  1435. the  F bit set from the other DXE, the DXE will initiate  a  link 
  1436. resetting procedure as described in 2.4.6, below.
  1437.  
  1438. 2.4.5  Frame Rejection Conditions
  1439.  
  1440.         A  DXE  shall initiate the frame-reset procedure  when  a 
  1441. frame  is received with the correct FCS and address field  during 
  1442. the information-transfer state with one or more of the conditions 
  1443. in 2.3.4.3.3, above.
  1444.  
  1445.         Under these conditions, the DXE will ask the other DXE to 
  1446. reset  the  link by transmitting a FRMR response as  outlined  in 
  1447. 2.4.6.3, below.
  1448.  
  1449.         After sending the FRMR frame, the sending DXE will  enter 
  1450. the  frame reject condition.  This condition is cleared when  the 
  1451. DXE that sent the FRMR frame receives a SABM or DISC command,  or 
  1452. a DM response frame.  Any other command received while the DXE is 
  1453. in the frame reject state will cause another FRMR to be sent  out 
  1454. with the same information field as originally sent.
  1455.  
  1456.         In  the  frame rejection condition, additional  I  frames 
  1457. will not be transmitted, and received I frames and S frames  will 
  1458. be discarded by the DXE.
  1459.  
  1460.         The DXE that sent the FRMR frame shall start the T1 timer 
  1461. when  the  FRMR is sent.  If no SABM or DISC  frame  is  received 
  1462. before the timer runs out, the FRMR frame shall be retransmitted, 
  1463. and   the  T1  timer  restarted  as  described  in  the   waiting 
  1464. acknowledgement section (2.4.4.9) above.  If the FRMR is sent  N2 
  1465. times without success, the link shall be reset.
  1466.  
  1467. 2.4.6  Resetting Procedure
  1468.  
  1469. 2.4.6.1  
  1470.      The   resetting  procedure  is  used  to   initialize   both 
  1471. directions  of  data  flow  after  a  nonrecoverable  error   has 
  1472. occurred.   This resetting procedure is used in the  information-
  1473. transfer state of an AX.25 link only.
  1474.  
  1475. 2.4.6.2  
  1476.      A DXE shall initiate a reset procedure whenever it  receives 
  1477. an unexpected UA response frame or an unsolicited response  frame 
  1478. with  the  F bit set to one.  A DXE may also initiate  the  reset 
  1479. procedure  upon receipt of a FRMR frame.  Alternatively, the  DXE 
  1480. may  respond to a FRMR by terminating the connection with a  DISC 
  1481. frame.
  1482.  
  1483. 2.4.6.3  
  1484.      A  DXE  shall  reset the link by sending a  SABM  frame  and 
  1485. starting  timer  T1.  Upon receiving a SABM frame  from  the  DXE 
  1486. previously connected to, the receiver of a SABM frame should send 
  1487. a  UA  frame back at the earliest opportunity, set its  send  and 
  1488. receive  state  variables,  V(S) and V(R), to zero  and  stop  T1 
  1489. unless it has sent a SABM or DISC itself.  If the UA is correctly 
  1490. received by the initial DXE, it resets its send and receive state 
  1491. variables, V(S) and V(R), and stops timer T1.  Any busy condition 
  1492. that previously existed will also be cleared.
  1493.  
  1494.         If  a  DM response is received, the DXE  will  enter  the 
  1495. disconnected  state  and  stop timer T1.  If timer  T1  runs  out 
  1496. before  a UA or DM response frame is received, the SABM  will  be 
  1497. retransmitted  and timer T1 restarted.  If timer T1 runs  out  N2 
  1498. times,  the  DXE  will  enter the  disconnected  state,  and  any 
  1499. previously existing link conditions will be cleared.
  1500.  
  1501.      Other  commands  or  responses received by  the  DXE  before 
  1502. completion of the reset procedure will be discarded.
  1503.  
  1504. 2.4.6.4  
  1505.      One  DXE  may request that the other DXE reset the  link  by 
  1506. sending  a  DM response frame.  After the DM frame is  sent,  the 
  1507. sending DXE will then enter the disconnected state.
  1508.  
  1509. 2.4.7  List of System Defined Parameters
  1510.  
  1511. 2.4.7.1  Timers
  1512.  
  1513.         To   maintain  the  integrity  of  the  AX.25   level   2 
  1514. connection, use of these timers is recommended.
  1515.  
  1516. 2.4.7.1.1  Acknowledgement Timer T1
  1517.  
  1518.         The  first timer, T1, is used to make sure a DXE  doesn't 
  1519. wait  forever  for a response to a frame it  sends.   This  timer 
  1520. cannot be expressed in absolute time, since the time required  to 
  1521. send frames varies greatly with the signaling rate used at  level 
  1522. 1.   T1  should take at least twice the amount of time  it  would 
  1523. take  to send maximum length frame to the other DXE, and get  the 
  1524. proper response frame back from the other DXE.  This would  allow 
  1525. time for the other DXE to do some processing before responding.
  1526.  
  1527.         If  level  2 repeaters are to be used, the  value  of  T1 
  1528. should be adjusted according to the number of repeaters the frame 
  1529. is being transferred through.
  1530.  
  1531. 2.4.7.1.2  Response Delay Timer T2
  1532.  
  1533.         The  second timer, T2, may be implemented by the  DXE  to 
  1534. specify  a maximum amount of delay to be introduced  between  the 
  1535. time an I frame is received, and the time the resulting  response 
  1536. frame is sent.  This delay may be introduced to allow a receiving 
  1537. DXE to wait a short period of time to determine if there is  more 
  1538. than  one frame being sent to it.  If more frames  are  received, 
  1539. the  DXE can acknowledge them at once (up to seven), rather  than 
  1540. acknowledge  each individual frame.  The use of timer T2  is  not 
  1541. mandatory,  but  is recommended to  improve  channel  efficiency.  
  1542. Note  that, on full-duplex channels, acknowledgements should  not 
  1543. be delayed beyond k/2 frames to achieve maximum throughput.   The 
  1544. k parameter is defined in 2.4.7.4, below.
  1545.  
  1546. 2.4.7.1.3  Inactive Link Timer T3
  1547.  
  1548.         The third timer, T3, is used whenever T1 isn't running to 
  1549. maintain  link integrity.  It is recommended that whenever  there 
  1550. are  no  outstanding  unacknowledged I  frames  or  P-bit  frames 
  1551. (during  the information-transfer state), a RR or RNR frame  with 
  1552. the  P  bit set to one be sent every T3 time units to  query  the 
  1553. status  of the other DXE.  The period of T3 is  locally  defined, 
  1554. and  depends greatly on level 1 operation.  T3 should be  greater 
  1555. than T1, and may be very large on channels of high integrity.
  1556.  
  1557. 2.4.7.2  Maximum Number of Retries (N2)
  1558.  
  1559.         The maximum number of retries is used in conjunction with 
  1560. the T1 timer.
  1561.  
  1562. 2.4.7.3  Maximum Number of Octets in an I Field (N1)
  1563.  
  1564.         The maximum number of octets allowed in the I field  will 
  1565. be 256.  There shall also be an integral number of octets.
  1566.  
  1567. 2.4.7.4  Maximum Number of I Frames Outstanding (k)
  1568.  
  1569.         The  maximum number of outstanding I frames at a time  is 
  1570. seven.
  1571.  
  1572.                               END.
  1573.